It's worthwhile pointing out there is some prior art on using these types of variables on resources https://www.terraform.io/docs/providers/aws/r/route53_zone.html#force_destroy

It's worthwhile pointing out there is some prior art on using these types of variables on resources https://www.terraform.io/docs/providers/aws/r/route53_zone.html#force_destroy

I understand the desired behavior for a dns zone which can contains other records managed outside of terraform.
The zone is a container object which hold child records. Because of that it's useful to control the action on child object when you destroy the container.

For a single environment variable, I'm less sure it is useful.
If you want to remove a CircleCI EnvironmentVariable from terraform while keeping it in CircleCI Example: you initially managed it with terraform and want to manage it with something else now.

To do that, you can remove its declaration from your terraform sourcecode and do a terraform state rm <CircleCI EnvVar resource ID in terraform>.

As far as I understand your code, doing a terraform state rm have the same intent: remove the resource from terraform state and not altering it in CircleCI.

Can you provide a bit more info about use case where you don't want to clear out env vars when the resources is destroyed ?

For our particular use case we have a single environment managed ~3800 pairs CircleCI environment variables, i.e. ~7600 individual resources. Each resource is not individually instantiated, but defined in a standard module for publishing permissions that is invoked many times. Each invocation can take n number of Circle project names generating a user/password pair as environment variables.

Our problem comes around when you move a Circle project from one module to another; there is no way to carry the reference across. This means we get a race condition where Terraform tries to "create" an environment variable that is already there before the delete has taken place.
Adding this option will allow us to delete the environment variable from the state whilst using #32 to update that variable and bringing it under management.

For reference the workspace/repo that manages these resources is updated 50+ times a week and changes to Circle projects are consider something that requires no human interaction to approve that PR. Sadly, that means we can't and won't be doing state file surgery to move the projects around

I'm not sure I understand how #32 you in that case: it adds retries on creation but it still checks for variable existence before trying to create it.